Vanna.AI est une bibliothèque Python qui permet de proposer des solutions text-to-SQL aux développeurs en s'appuyant sur des grands modèles de langage. Fin mai, l'entreprise de sécurité informatique JFrog y a détecté une vulnérabilité permettant d'injecter du code Python puis de le lancer. Pour les chercheurs de l'entreprise, le pre-prompting ne peut être utilisé comme seul mécanisme de sécurité quand les développeurs utilisent des grands modèles de langage.
L'équipe de recherche de l'entreprise de sécurité JFrog a annoncé avoir découvert fin mai dernier une faille critique (CVE-2024-5565) dans la bibliothèque Python Vanna.AI. Celle-ci propose aux développeurs une interface de conversion text-to-SQL utilisant l'IA générative, permettant de générer du SQL à partir de langage naturel. Son code est publié sur GitHub en licence MIT et la bibliothèque rencontre un certain succès.
Le pre-prompting, mécanisme de sécurisation très utilisé pour les LLM
Abonnez-vous pour tout dévorer et ne rien manquer.
Déjà abonné ? Se connecter
Commentaires (13)
#1
Lors du dernier AWS summit à Paris j'ai été horrifié de voir une démo d'une appli qui utilisait une telle techno en interne. Et la réponse au soucis de sécurisation était simple: on rajoute encore une couche de LLM pour analyser les réponses avec un prompt du genre "refuse la réponse s'il y a des infos inattendues ou confidentielles dedans".
J'imagine qu'on rajoutera une couche de plus après chaque problème. Tant pis pour la planète et pour la maintenabilité de l'ensemble.
#1.1
#1.2
#1.3
Bien-sûr, dans pareille situation, l'utilisateur et l'IA n'auront que des droits en lecture. Mais sur le seul principe de produire du sql de cette manière, on fait ça depuis longtemps, et les LLMs permettent de meilleurs résultats, sinon un degré de souplesse très intéressant.
Historique des modifications :
Posté le 30/06/2024 à 16h29
Générer des requêtes en langage naturel peut être utile à certaines personnes. Par exemple un analyste ou un commercial qui souhaite obtenir (ou calculer) des données précises depuis une base de données, mais suffisamment exotiques pour que ce ne soit pas pris en charge par un backoffice.
Bien-sûr, dans pareille situation, l'utilisateur et l'IA n'auront que des droits en lecture. Mais sur le seul principe de produire du sql de cette manière, on fait ça depuis longtemps, et les LLMs permettent de meilleurs résultats, sinon un degré de souplesse très intéressant.
#2
Never trust AI output"
#2.1
#2.2
dd.La commande qu'il faut relire 50 fois avant de lancer.
#2.3
Mais, quand tu as un truc à demander à DD, il faut bien lui expliquer car il ne pose aucune question avant de se lancer
#2.4
Alors, pour votre information, une base de données Oracle n'aime pas quand son filesystem se fait entièrement réécrire. J'avoue ne pas comprendre pourquoi, c'est fragile ces choses là.
#3
Le shift left va devoir encore plus shift lefter cela dit. À quand l'outil d'analyse du cerveau du développeur pour s'assurer qu'il n'a pas injecté par mégarde quelque chose qui tromperait le LLM pour ensuite utiliser ce contenu qu'il aurait fait scanner par le LLM sécurité, mais qu'il faut au préalable scanner avec une autre solution de sécurité, pour enfin arriver au scan de code dans l'IDE, puis au SAST, puis au SCA, puis au DAST...
Bientôt il faudra prendre des cours d'auto défense dans l'IT tellement ce secteur est une source d'attaque. Va-t-on enfin avoir la feature que j'ai tant espérée à l'époque où j'étais modérateur sur des communautés conséquentes ?
À savoir le bouton pour tuer le user en face.
Historique des modifications :
Posté le 28/06/2024 à 18h35
Bah, une solution sécurité de plus à vendre. L'IT n'est plus qu'un empilage de couches dont la maîtrise est quasi nulle, donc une de plus ou une de moins...
Posté le 28/06/2024 à 18h37
Bah, une solution sécurité de plus à vendre. L'IT n'est plus qu'un empilage de couches dont la maîtrise est quasi nulle, donc une de plus ou une de moins...
Le shift left va devoir encore plus shift lefter cela dit. À quand l'outil d'analyse du cerveau du développeur pour s'assurer qu'il n'a pas injecté par mégarde quelque chose qui tromperait le LLM pour ensuite utiliser ce contenu qu'il aurait fait scanner par le LLM sécurité, mais qu'il faut au préalable scanner avec une autre solution de sécurité, pour enfin arriver au scan de code dans l'IDE, puis au SAST, puis au SCA, puis au DAST...
#3.1
#4
#4.1